![[アップデート] Amazon AppStream 2.0に新しいApplications Managerが登場しました](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-appstream-20.png)
[アップデート] Amazon AppStream 2.0に新しいApplications Managerが登場しました
しばたです。
先日AWSよりAmazon AppStream 2.0に新しいApplications Managerという機能を追加した旨のアナウンスがありました。
この内容だけだとかなり分かりにくいので本記事で解説したいと思います。
何が新しくなったのか？
まずはじめに言っておく必要がある点として、本更新はElastic Fleetsに対する更新となります。
On-Demand Fleets/Always-On Fleetsは一切関係しません。
Elastic Fleetsが何かについては以下の記事で解説してますのでまずはこちらをご覧ください。
上記記事にある通り、Elastic Fleetsでは専用のベースイメージを作る代わりにVHDファイルをベースとしたApp Blockという塊を使い公開アプリケーションを管理します。
今回の更新はこのApp Blockに新しい方式のものが増え、「Application」として管理していた従来のUIが「Applications Manager」に刷新されました。
App block builders
今回増えた新しい方式のApp Blockは「AppStream 2.0 App Block」と呼称されています。
VHDファイルで公開アプリケーションを管理する点は変わりないのですが、従来のVHDファイルとセットアップスクリプトをセットにしていた方式とは異なり、公開アプリケーションインストール時のファイルシステムおよびレジストリ値の変更を記録してVHDファイルに残すことでセットアップスクリプトを不要にする方式になっています。
そしてアプリケーションインストール時の変更を記録するために新しく「App Block Builder」という機能が増えました。
これはざっくり従来のImage BuilderのApp Block版だと考えてもらればOKです。Image Builder同様に専用のApp Block Builderインスタンスを起動し、インスタンス内でアプリケーションをインストールしてその変更点をVHDファイルに保存する仕組みとなっています。
App Blockから「Application」を作りElastic Fleetと紐づける手順は概ね従来どおり変わりありません。
「セットアップスクリプトが不要になる分お手軽になるだろう」というのがAWSの目論見の様です。
ちなみに従来のApp Blockは「Custom App Block」と呼称される様になりました。
AppStream 2.0 App Blockの制限
一見便利そうに見えるAppStream 2.0 App Blockですが、仕組み上いくつかの制限があります。
まず現時点でAppStream 2.0 App BlockはWindows Server専用機能です。
AWSが独自に用意したフィルタドライバーを使いファイルシステム(レジストリ含む)の変更をフックして記録するためLinuxには対応してません。
加えてこのフィルタドライバーは%USERPROFILE%配下のユーザー領域[1]およびHKEY_CURRENT_USER配下のレジストリキーの変更を記録しないためユーザー別にインストールするアプリケーションには使えません。
また、ファイルシステムの変更をテンポラリ領域[2]に記録する都合、インストール時に保存されたパスをチェックするアプリケーションではエラーになる可能性があるとのことです。
試してみた
ここまで解説しても正直伝わりにくいと思っています。
私自身実際に動作確認してやっと理解できた点が多いので、ここからは試した内容をお伝えしていきます。
検証条件
今回私の検証用AWSアカウントの東京リージョンで試しています。
AppStream 2.0 App BlockやFleetの利用にVPC環境が必要になりますが、こちらの構築手順は割愛します。
(とりあえず試すだけならDefault VPCを使って構いません)
また、本記事の主題とならない一般的なAppStream 2.0環境の構築手順については一部割愛することがありますのでご了承ください。
0. 事前準備 (S3の用意)
従来のApp Block同様VHDファイルを保存するS3を用意しAppStream 2.0からのアクセスを許可する必要があります。
従来のApp Blockはユーザーが作成したVHDファイルなどを参照するだけでしたのでs3:GetObjectだけ許可すればOKでしたが、今回はAppStream 2.0のサービスがVHDファイルを作成する都合以下の様に書き込み系の権限も必要となります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAppStream2.0ToPutAndRetrieveObjects",
"Effect": "Allow",
"Principal": {
"Service": [
"appstream.amazonaws.com"
]
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"s3:GetBucketOwnershipControls"
],
"Resource": [
"arn:aws:s3:::bucket",
"arn:aws:s3:::bucket/VHD object",
"arn:aws:s3:::bucket/Setup script object",
"arn:aws:s3:::bucket/Application icon object",
"arn:aws:s3:::bucket/Session scripts zip file object"
]
}
]
}
今回はelastic-fleets-sample-20230701と言う名前のS3バケットを新規に用意し、以下のバケットポリシーを設定しておきました。
1. App Block Builderの作成
ここからAppStream 2.0の設定に入ります。
マネジメントコンソールにアクセスすると左ペインの「Applications」欄が「Applications Manager」に変わっており、アクセスすると新たに「App block builders」タブが増えています。
「App block Builders」タブにはまだ何もないので「Create app block builder」をクリックして新しいBuilderを作成します。
作成画面で選ぶ内容は概ねImage Builderの時と同じです。
名前とOS(現時点ではWindows Server 2019 Baseのみ)、インスタンスタイプを選び次へ進みます。
続けてBuilderインスタンスを配備するVPC情報を設定し、
最後に設定内容の確認をしてBuilderを作成します。
Builder自体は直ちに作成され、停止された状態になります。
2. App Blockの作成
続けてApp Blockを作成し、同時にApp Block Builderとの紐づけを行います。
「App blcoks」タブから「Create app block」を選びます。
下図では既存のApp Blockがありますが、ご覧の通りPackagint typeがCustomになっています。
作成ウィザードが開始され、今回新たに「App Stream 2.0 app block」が増えてますのでこれを選んで次へ進みます。
次にApp Blockの各種設定を行います。
今回名前はpwsh-win-as2とし、VHDファイルを保存するS3バケットにs3://elastic-fleets-sample-20230701を指定しています。
画面下部にApp block builderの指定欄があるため前項で作成したBuilderをチェックして次へ進みます。
最後に設定内容の確認をして「Launch app block builder」をクリックします。
するとApp Block設定の作成と同時にApp Block Builderが起動されます。
3. アプリケーションのインストール
App Block Builderが起動され接続すると以下の画面になります。
だいたいImage Builderと同じ感じですがベースとなるOSはElastic Fleet用の英語版です。
専用ツールの「Application builder Assistant(Image Assistantではない)」がインストールされており、これを使いアプリケーションインストール時の変更を記録します。
Application builder Assistantを使う前にアプリケーションのインストールに必要なファイル(インストーラーなど)をBuilder内に用意してきます。
インターネットからダウンロードする、ローカルからアップロードする、など方法は何でも構いません。
今回はPowerShell 7.3.5のMSIインストーラーを準備しました。
準備ができたらデスクトップにある「Application builder Assistant」のショートカットをダブルクリックして起動します。
すると下図のウィンドウが表示され、画面にはツールの使い方と注意事項が記載されていますので一読しておいてください。
画面下部にある「Start recording」の青ボタンをクリックするとファイルシステムへの変更が記録されはじめます。
記録中はこんなUIに変わります。
ここで用意したインストーラーを起動しアプリケーション(今回はPowerShell 7.3.5)をインストールします。
(デフォルト設定でインストール)
アプリケーションのインストールが完了したらApplication builder Assistantの「Stop recording」ボタンをクリックして記録を停止します。
停止が完了したら「Next」ボタンをクリックして次へ進みます。
記録内容が表示されるので「Finish app block creation and disconnect」ボタンをクリックするとVHDファイルをS3にアップロードします。
すべての処理が終わると自動でApp Block Builderから切断されます。
今回の場合、C:\Windows\Temp配下のフォルダにVHDファイルがマウントされインストール時に追加・更新されたファイルが保存されているのが見て取れました。
S3側はこんな感じです。
/AppStream2/"App Block名"/配下にVHDファイルが作成されてます。
VHDファイルの中身はこんな感じです。
ファイルシステムの変更はvol配下に、レジストリの変更は各種.regファイルに記録されます。AppBlockManifestフォルダにはOS上の実ファイルパスとVHD内フォルダのマッピング情報をまとめたJSONファイルもありました。
App Blockの作成はこれで完了です。
4. Applicationの作成
Applicationの作成は概ね従来通りです。
今回はpwsh-win-as2と言う名前のアプリケーションにします。
公開アプリケーション用のアイコンファイルが必要になりますので、予めS3にアップロードしておいてください。
(予め適当なpngファイルをs3://elastic-fleets-sample-20230701/app-icon.pngにアップロード済み。手順は割愛)
Application Settingの設定も概ね従来通りです。
従来であればセットアップスクリプトの内容次第で実行ファイルのパスが変わりましたが、今回はApp Block Builderでインストールした際のインストール先を指定してください。
AppStream 2.0のサービス側でFleetの起動時にVHDファイルからいい感じにインストール内容を復元してくます。
作成結果はこんな感じです。
5. Fleetの用意
Fleetの作成方法は従来通り変わりありません。
新しくElastic Fleetを作成し、前項で作成したpwsh-win-as2アプリケーションを利用する様にしてください。
既存のFleetがあればそれを使っても構いません。
6. Stack設定など
Stackの作成およびFleetの紐づけなどの作業は従来通りなので割愛します。
環境に応じてよしなに設定してください。
7. 動作確認
最後に作った環境に接続して動作確認します。
今回はWindows Clientから接続します。
AppStream 2.0環境にログインするとちゃんとApplicationが表示されています。
アプリケーションを起動してやるとちゃんとインストールパスが復元されています。
いい感じですね。
最後に
以上となります。
アプリケーションインストール時の操作を記録することでVHDファイル作成の省力化しセットアップスクリプトを不要にするアプローチは面白いですが、すべてのアプリケーションで適用可能ではないので導入に際し動作検証は入念に行う必要があるでしょう。
アプリケーション導入の自動化を多くやってきた私みたいな人間からすると自分でコントロール可能な範囲が多いCustom App Blockの方が正直やりやすいと感じてしまいます。
逆に「できる限りAWS側の仕組みに任せて省力化したい」場合はAppStream 2.0 App Blockがハマりそうです。
用途に応じて両者を上手に使い分けると良いでしょう。
